In security systems, verifiers are used to authenticate, that is to verify the identity of, a person or other entity such as a computer. When an entity has been authenticated, meaning that the identity of the entity has been determined by the verifier, the entity is allowed access, for example physical access to a physical location, in the case of a physical security system, or electronic access to information (e.g. financial records, computer data, network access, etc.), in data security systems.
There are many possible configurations for verifiers. Verifiers can receive input from keypads, keyboards, card readers, cameras, microphones, telephone and computer networks, and other such data input devices. As output, verifiers activate physical mechanisms, send electronic data signals, configure software, or take such other action to provide access. Verifiers can be implemented in various ways, for example as special purpose electronic and/or mechanical systems, or as general purpose computers, possibly, but not necessarily, in electrical communication with special-purpose hardware.
Some verifiers use knowledge of a shared secret to authenticate an entity. For example, knowledge of a personal identification number, password, or passphrase can be used to verify an entity. At the time that authentication takes place, the entity either reveals the secret or otherwise proves knowledge of the secret. If the entity shows knowledge of the secret, the entity is authenticated.
In some systems, an entity uses a physical or digital device, referred to as a token, that incorporates a secret. The secret, stored in some manner in the device, may or may not be known to the entity using the device. A common door key is one simple mechanical example of such a device. The shape of the key is a shared secret. When a key is inserted into a lock, the lock verifies that the key is of the correct shape. The door key shows knowledge of the secret to the verifier (the lock), and allows entry. An attacker who learns the exact shape of the key can generate an appropriate token and authenticate to the lock.
A bank card is a device that can contain a secret identification number that is revealed when the card is accessed by an automatic teller machine (“ATM”). Some bank cards incorporate cryptography to make forging of bank cards more difficult. Also, to provide an added layer of security, automatic teller machines require the user to possess the device (bank card) containing secret information, and require the user to enter a Personal Identification Number (“PIN”), which is another secret shared between the bank's verifier and the account holder.
Some devices, to prove knowledge of a secret contained within the device, provide an authentication code that is based upon, but different from, the secret code contained within the device. The use of such an authentication code allows the device to show knowledge of a secret without revealing it. In some systems, the authentication code is based on time-dependent information. The use of this sort of device has security benefits in that the secret is more difficult to determine by eavesdropping in the communications channel between the entity and the verifier, since the secret itself is not revealed.
One example of this sort of device used by a person to authenticate to a verifier is a token that includes an authentication code display. The person reads an authentication code from the display, and transmits the authentication code to the verifier. In such a system, the user may never know the shared secret. Some such tokens accept user input, such as a PIN, and provide a result in response to the user input as well as other information (such as time-dependent information).
One token of this type stores a secret code, referred to as a seed, and mathematically combines the secret code with a time-varying value and a personal identification code provided by the user to generate an authentication code. The mathematical combination takes place in such a way that the secret code stored in the token cannot be determined from the result—the secret code is combined cryptographically with the current time and other information. In another system that is a challenge-response system, meaning that the verifier transmits a challenge for the user to respond to, the secret code is cryptographically combined with the challenge to produce an output that is sent to the verifier as a response to the challenge.
To verify an entity using a shared secret, the verifier needs to have knowledge of the shared secret. In a security system that verifies a large number of entities, there is a tradeoff between security and verifier availability. If there are a large number of verifiers, there is more likely to be a verifier available when a particular entity requires authentication. However, as the number of verifiers that have knowledge of a secret increases, it is increasingly more difficult to maintain the secrecy of the secret. For example, as the number of verifiers increases, so does the chance that one of the verifiers can be compromised in some fashion. Yet, if the number of verifiers is limited, it possible that a verifier will not be available to authenticate an entity when the entity requires authentication.
In addition, a single device presently cannot be used to access multiple independent services. For example, the same device cannot be used to access an enterprise's computer system and a financial institution's web page. Even if each independent service trusts the user and the device, the services do not trust each other. In the example just mentioned, a bank does not trust the user's employer. If each of the services share the same secret with the device, then each service has information that can compromise the others. This prevents use of a single device from being used with verifiers associated with independent services.
The utility of a security system is limited by the number and variety of verifiers to which an entity can conveniently authenticate. If the entity interacts with a number of verifiers that share different secrets with that entity, the entity will have to manage a number of secrets (or devices containing secrets), where each secret is used to authenticate to one or small number of verifiers. Managing a large number of secrets adds complexity to a computer-based entity, and is inconvenient for a human entity. Even the process of securely sharing a different secret between an entity and each of a large number of verifiers can be inconvenient and cumbersome.
Similar issues arise in the area of secure communications, where a single shared secret is used as an encryption key. To communicate securely with many other entities, an entity either has to have a separate shared secret with each other entity, or has to share the same secret with more than one entity, thereby reducing the secrecy (and security) of the shared secret.
Public key cryptography can be used to avoid the need to securely share a secret between each two parties that wish to communicate or authenticate. However, public-key cryptography is impractical in many user and device authentication settings, at least partly because of the large computation power required to accomplish the calculations, and the complexity of managing certificates and revocation lists.